Part 43: Assignment #19: Control Router - IMPORTANT

Control Router - IMPORTANT



Another day, another job. This is, interestingly, the first job in a while that's a repeat visit - and from Sun Haotian, no less. Let's see what he's after this time...









Well, this is interesting. The part of the meter I'm designing is mostly just a rebroadcaster. I initially thought that I'd have to hook up an individual chip to each input, but Carl set me straight - I can wire the inputs all up together and one MC can read them all on a single pin.

The other interesting thing is that little chip with the lock icon in the center of the board. Here's what the datasheet has to say about it:



From my perspective, it's no different than reading from a dial. From an overall design perspective - holy moly. Not only is 'Ronan R. Dornan' a heck of a name, but if the description is right, it's an inalterable locked box from a tinkerer's perspective. Sun Haotian is serious about whatever he's doing.

So now: how to make it work? It feels like one chip (probably a MC6000) COULD connect to all the pins and route stuff, but I'm going to have to experiment to find out if it's easily doable. A little not-so-ancient wisdom for David and all the nontechnical types of the world:
"In computers, what looks easy can be very hard, and what looks hard is often easy."

To work.

[ ~ ]

I tried. I really did. But there's a problem: I ran out of lines of code on my single MC.

Basically, when I read the first value in the packet (the destination), it's easy to tcp it with the ID value in the lock to set a destination. But I also have to rebroadcast that value out, so I need to store it - let's say in dat. In the same vein, I need to store how long the packet is, so I know when to stop – the inputs aren't non-blocking inputs like the radio, and will hang if I try to read past the end of a packet. So let's store the packet length in acc and use it as a counter.

The thing is, if you're going to do all of this in one chip, you need to send all the values out on one of three different XBus pins. Which means you need to include code that sends out the value you've chosen to a specific pin. You can do this with 5 lines of code: a tcp followed by two lines for two of the three pins, and then a teq for the last case and the line that sends to the third pin.

So far so good - but the lines that send to the pins would probably look something like mov x0 x2. They copy a value from input to output. They can't copy out the values we already read and stored in acc and dat— and those are the values that have to go out first!

So, there's two potential ways to solve this problem:

 

1. Put the code that routes the values in three times: one to route the destination address from dat to the right output pin, one to route the length from acc to same, and one to route everything else in the packet.

That's 15 lines of code right there. Even if you somehow combine all three pairs of conditionals together to eliminate redunancies, you've got three sets of three different mov lines, each with a different source and destination (mov acc x1/x2/x3, mov dat x1/x2/x3, and mov x0 x1/x2/x3) = 9 lines, plus two more for the conditionals themselves = 11 lines.

Then there's the matter of making a loop to read the rest of the packet, as well as reading the original first two values into acc and dat— all with three lines of code left to do it in, which is completely impossible. My best attempt, above, used 21 lines total - and that was with fusing several conditionals for redundancy.
Which brings us to the other option...

2. Use two chips.



 

...this design. Here, the comparison value gets turned into a simple I/O compatible number (remember, no negative numbers on simple I/O pins) and sent out on p1. The second MC can refer to this value as many times as it likes (because reading from simple I/O doesn't "use up" values), so that's the routing part of the problem solved. Then, the first chip sends the destination and length values to the second MC, and uses the loop to send the rest of the packet along, too.

The second MC is very dumb, and just sends any packet it gets to the output requested by the simple I/O line.

Stats: ¥10, 415 average power per run. It would be really nice if I could turn the second MC into a MC4000X, but that would require doing all this without a simple I/O line (sending the routing value - maybe repeatedly? - through XBus?)... I'm going to try to figure it out, as this is a big enough project that a cost improvement would definitely help.

[ ~ ~ ]



 

Here's the final version! It does away with the need for a simple I/O pin by using the second MC's acc to store the destination of the pulse.
The second MC now takes two to three values each time it's woken up: a first value, which is -999 if it needs to update its destination, and any other value otherwise.
If an update is required, the second MC reads another value and stores it in its acc.

From there, it's just a matter of reading the data to be sent, comparing acc with the lock, and sending the read value out to the correct output. The reason you can get away with putting the lock chip on one of the output lines is that you can't read from the output line! The lock aggressively read-only, as per the datasheet, and the output is write-only and you can't read from it, so if you try to read or write you'll always get the correct destination by virtue of not having anywhere else that'll accept the pulse.

The first MC now behaves like this:
(send -999 to update dest) (send destination, to store) (send destination to rebroadcast)
(send 0 - no update needed) (send packet length to rebroadcast)
loop: (send 0 - no update needed) (send next piece of packet to rebroadcast) and repeat as necessary.

This version's more power-hungry - 512 average power per run - but the design is only ¥8. And given this thing will be connected to the power grid at wherever-it's-installed, I don't think I need to worry about power usage as long as it's not really excessive.



So this is a subsystem, huh? I wonder if it's a subsystem for the same thing as the aquaponics kit was a subsystem for— but I'd say it seems unlikely, if only because I can't think of how the things could fit together.
Of course, for all I know, Mr. Haotian's going to keep commissioning us, and I'll be able to find out if/how it's all connected, or figure it out, in a hurry. But at this point, I'd say, "Outlook not so good".


P.S: Secret Project update! It looks like this now...




I'm about 30% complete, and it does the rhythm guitar now.
Next up: Incidental guitar/piano.